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Technical Field 



The present invention relates to the routing of signaling messages in 
a multi-protocol communications networking environment, and more 
particularly to methods and systems for providing message accounting 
10 services at an internetwork routing node that is also capable of receiving, 
translating, and routing signaling messages that utilize a variety of 
communication protocols. 



Background Art 

15 Shown in Figure 1 is a simplified communications network scenario 

that includes both a Signaling System 7 (SS7) and a Transmission Control 
Protocol / Internet Protocol (TCP/IP) communications network, generally 
indicated by the numeral 100. Network 100 includes both a conventional 
voice type calling party 102 and a computer terminal based data type calling 

20 party 104. Both calling parties are communicatively coupled to an originating 
End Office (EO) or Service Switching Point (SSP) 106. With particular 
regard to signaling type communications, SSP 106 is generally connected 
via an SS7 network 108 to an SS7 signaling message routing node, Signal 
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Transfer Point (STP) 110. Coupled to STP 110 is an SS7 message 
accounting and billing system 114 which is used to track SS7 signaling query 
messages lhat are destined for an SS7 database nocle; Service Cdnfrol 
Point (SCP) 112. SCP node 112 might include an 800 number database, a 
5 Line Information Database (LIDB), Local Number Portability database (LNP), 
or other database services typically associated with the Public Switched 
Telephone Network (PSTN). 

With particular regard to SS7 communication networks and the 
protocol stack typically employed therein, it will be appreciated that the 

10 overall stack can essentially be divided into two segments or layers: a lower 
level Message Transfer Part (MTP) layer and a higher level signaling 
application layer. In fact, the MTP layer, as described above, is comprised 
of three sub-levels that are identified as layers MTP1, MTP2 and MTP3. 
These three layers generally correspond to the physical, data link, and 

15 network levels as defined in the International Standards Organization (ISO) 
Open System Integration (OSI) protocol standard, and each layer can be 
configured to operate under one of many layer-specific protocols depending 
upon the particular network configuration scenario. For instance, the MTP1 
layer protocol could be configured as DSOA, V.35, etc. Signaling application 

20 layer protocols commonly employed in an SS7 network include Transaction 
Capabilities Application Part (TCAP)/Signaling Connection Control Part 
(SCCP), ISDN User Part (ISUP), Telephone User Part (TUP), Mobile 
Application Part (MAP) and Broadband ISDN User Part (BISUP). With 
respect to the OSI model mentioned above, these SS7 signaling application 

25 protocols essentially correspond to OSI layers 4 through 7, and in some 
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cases a portion of the OSI layer 3. Such signaling application layer protocols 
are concerned primarily with facilitating call setup/teardown and various call 
related services (e.g., toll free service; local number portability, calling name 
delivery, etc.). In general, it will be appreciated that the lower level MTP 
layers are concerned with, and responsible for, ensuring reliable transport of 
a signaling message between applications residing on different SS7 network 
nodes. 

In light of the previous discussion, it will be appreciated that within an 
SS7 signaling network, SS7 signaling protocol messages are typically 
transmitted over dedicated communication links that employ an MTP 
transport protocol suite. 

Returning to Figure 1, it will be noted that further connected to SSP 
106 is an Internet Service Provider (ISP) 116. which is also communicatively 
coupled to an Internet Protocol communications network 118, such as the 
Internet. As such, ISP 116 effectively provides a calling party that is served 
by SSP 106 with access to the Internet 118. Connected to and generally 
contained within the Internet "cloud" 118 are a large number of data packet 
routers, one of which is shown in Figure 1 as router 120. Further coupled to 
Internet data router 120 is a database node 122 and a billing system 124. 
Database node 122 might include domain name information, presence or 
status information, or any number of database applications utilized by 
Internet type service providers or e-commerce type operators. In a manner 
similar to that described above, billing system 124 is coupled to router 120 
so as to generally track messages destined for Internet database node 122. 




With particular regard to IP-based communication networks and the 
protocol stack typically employed therein, in a manner analogous to that 
described above for-SS7/MTP protocols, it will again be appreciated that the 
overall stack can essentially be divided into two components: a lower level or 
5 suite of transport related protocols and a higher level signaling application 
related layer. For the case of a Transmission Control Protocol (TCP) / IP 
based communication network, it will be appreciated that the transport 
protocol suite, as referred to herein, refers to OSI layers 1 through 3. 
Consequently, with regard to TCP/IP based communication, OSI layers 4 

10 through 7 are referred to herein as the higher level or signaling application 
related layers. Again, as both the ISO OSI and the SS7/MTP protocol 
models are well known to those skilled in the art of packet network 
communications, a detailed description and discussion of the basic OSI and 
SS7/MTP models is not presented herein. A detailed discussion of the OSI 

15 model can be found in Communications for Cooperating Systems OSI, SNA, 
and TCP/IP by R.J, Cypser, Addison-Wesley Publishing Company, Inc., 
1991. Similarly, a detailed discussion of the SS7/MTP protocol can be found 
in Signaling System #7 by Travis Russell, 2""^ ed. McGraw-Hill, Inc., 1998. 

Given the configuration of network 100, and the inherent 

20 incompatibility of the two communication transport protocol suites (MTP vs. 
TCP/IP), there is no way that an Internet protocol node can directly or 
indirectly access a database node in the SS7 component of the network. 
Similarly, there is no mechanism whereby an SS7 node can access a 
database node in the IP component of the network. 
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One solution to the above stated problem is to employ a stand-alone 
protocol converter node 126 that resides in front of the SS7 SCP node 112 
as indicated in Figure 2. Protocol converter node 126 is capable of "receiving^ 
a TCP/IP based non-SS7 database query message (i.e., a message that 
5 employs a non-SS7 signaling application protocol such as session initiation 
protocol (SIP), H.323, etc.) and translating this message into an SS7/MTP 
formatted query message that can be processed by SCP 112. However, as 
indicated in Figure 2, such a configuration makes the problem of message 
accounting / billing considerably more complicated, as all query messages 

10 destined for SCP 112 do not necessarily pass through STP 110. 
Furthermore, such a configuration requires that a network operator install 
and maintain separate protocol converting nodes, which generally increases 
network complexity and creates additional OA&M burdens. 

What is neede.d is a system and method of providing a packet routing 

15 node that is capable of facilitating communication between networks that 
employ differing transport level protocols (e.g., MTP vs. TCP/IP) and 
differing signaling application level protocols (e.g., SS7 vs. SIP). Also 
needed is the ability for such a multi-protocol routing node to simultaneously 
provide centralized message accounting and billing capability in a multi- 

20 protocol communication network environment. 

Disclosure of the Invention 
According to one aspect, the present invention includes a 
communications network element that is capable of generally receiving, 
25 processing and routing signaling messages between communication 
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networks that employ differing signaling application protocols. Furthermore, 
the communications network element, referred to herein as a Multi-Protocol 
_ Gateway (MPG) routing node^ is adapted- to make a routing decision, 
perform message translation at both the transport protocol suite and 
5 signaling protocol levels as required, so as to generally facilitate signaling 
message transmission to a node in a non-SS7 network. It will be 
appreciated that herein a transport protocol suite refers to the collection of 
lower level stack protocols associated with the transport of signaling 
message packets through a communications network, such as Message 
10 Transfer Part (MTP) or Transmission Control Protocol / Internet Protocol 
(TCP/IP). 

It will be further appreciated that herein, a signaling application 
protocol refers to the particular type of higher level signaling protocol used in 
a communications network, such as SS7. SIP, H.323. or Normalized Call 

15 Control Protocol (NCCP). The session initiation protocol is defined in SIP: 
Session Initiation Protocol. RFC 2453. IETF Network Working Group (March 
1999), the disclosure of which is incorporated herein by reference in its 
entirety. H.323 is defined in ITU Recommendation H.323: Packet Based 
Multimedia Systems (September 1999), the disclosure of which is 

20 incorporated by reference in its entirety. The normalized call control protocol 
is a protocol used by an SS7/IP gateway for communicating ISUP messages 
of a given national format to a normalized format for delivery to IP devices 
and vice versa. The MPG is further configured to update an integrated 
message accounting and billing system based on certain predetermined 

25 message criteria. Once again, it will be appreciated that an MPG routing 




node is adapted to make a routing decision, perform message translation at 
both the transport suite and signaling application protocol levels as required, 
so as to generally facilitate signaling message transmission to a node"in a 
destination network that does not necessarily employ the same signaling or 
5 transport protocol suites as the network from which the message originated. 
Again, the MPG is further configured to update an integrated message 
accounting and billing system based on certain pre-determined criteria. 

In one embodiment, the MPG routing node includes a communication 
module or modules capable of transmitting and receiving data packets over 

10 MTP, TCP/IP, UDP/IP, and Stream Control Transmission Protocol (SCTPyiP 
based networks, wherein these data packets may employ SS7, SIP, H.323, 
NCCP or similar signaling protocols. The SCTP protocol is a protocol for 
transferring SS7 messages over an IP network. SCTP is defined in Stream 
Control Transmission Protocol <draft-ietf-sigtran-sctp-10.txt>, IETF Network 

15 Working Group (June 16, 2000), the disclosure of which is incorporated 
herein by reference in its entirety. 

With particular regard to the transmission of SS7 information through 
TCP/IP type communication networks, the Assignee of the present 
application has previously disclosed a protocol (Transport Adapter Layer 

20 Interface, TALI) that was developed specifically for such an MTP-to-TCP/IP 
transmission scenario. A detailed description of the TALI protocol may be 
found in the TALI 2,0 Technical Reference, published by Tekelec, Inc. of 
Calabasas, California (June 2000). the disclosure of which is incorporated 
herein by reference in its entirety. The TALI protocol is also described in 

25 detail in commonly-assigned, copending U.S. Patent Application No. 



09/588.852, filed June 6, 2000, and in Patent Cooperation Treaty Publication 
No. WO 00/35156, published June 15, 2000, the disclosures of each of 
which are incorporated herein by reference in their e^ 

The functions for providing MPG routing and accounting services are 
5 described herein as modules or processes. It is understood that these 
modules or processes may be implemented as computer-executable 
instructions embodied in a computer-readable medium. Alternatively, the 
modules or processes described herein may be implemented entirely in 
hardware. In yet another alternative embodiment, the modules or processes 
10 described herein may be implemented as a combination of hardware and 
software. 

The processes and modules for providing MPG routing and 
accounting services are described below as being associated with cards or 
subsystems within a routing node. It is understood that these cards or 
15 subsystems include hardware for storing and executing the processes and 
modules. For example, each card or subsystems described below may 
include one or more microprocessors, such as an x86 or Pentium® 
microprocessor available from Intel Corporation, and associated memory. 

Accordingly, it is an object of the present invention to provide a 
20 routing node that facilitates the routing and accounting of messages 
between a plurality of network elements that do not share a common 
signaling application protocol. 

It is another object of the present invention to provide a routing node 
that facilitates the accounting and routing of messages between a plurality of 
25 network elements that do not share a common transport protocol suite. 

1 
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It is another object of the present invention to provide a routing node 
that facilitates the pre-routing translation of a received signaling message 
employing a first signaling- protocol into a second signaling message that 
employs a Normalized Call Control Protocol (NCCP), 
5 It is another object of the present invention to provide a multi-protocol 

routing and accounting node that is capable of determining the destination 
and corresponding routing address of a signaling message based, at least in 
part, on a particular service requested by the incoming message. 

It is another object of the present invention to provide a multi-protocol 
10 routing and accounting node that is capable of determining the destination 
and corresponding routing address of a signaling message based, at least in 
part, on the message type of the incoming message. 

It is another object of the present invention to provide a multi-protocol 
routing and accounting node that is capable of determining the destination 
15 and corresponding routing address of a signaling message based, at least in 
part, on an intermediate destination address specified in the message. 

It is another object of the present invention to provide a multi-protocol 
routing and accounting node that is capable of determining the destination 
and corresponding routing address of a signaling message based, at least in 
20 part, on an origination or sending address specified in the message. 

It is another object of the present invention to provide a multi-protocol 
routing and accounting node that is capable of determining the destination 
and corresponding routing address of a signaling message based, at least in 
part, on calling or called party information specified in the message. 
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It is another object of the present invention to provide a multi-protocol 
routing and accounting node that is capable of determining the destination 
~ and corresponding routing" address of a signaling message based, at least in 

part, on ownership of a destination network node. 
5 It is another object of the present invention to provide a multi-protocol 

routing and accounting node that is capable of determining the destination 
and corresponding routing address of a signaling message based, at least in 
part, on ownership of a network node that originated the message. 

It is another object of the present invention to provide a routing and 
10 accounting node that is capable of receiving signaling messages having 
different transport protocol suites and signaling application protocols, 
wherein all messages are addressed to the routing and accounting node, 
and wherein the routing and accounting node further determines where to 
route the message and subsequently translates the message into the proper 
15 transport protocol suite and signaling protocol necessary for delivery to the 
destination. 

Some of the objects of the invention having been stated hereinabove, 
other objects will become evident as the description proceeds, when taken in 
connection with the accompanying drawings as best described hereinbelow. 

20 

Brief Description of the Drawings 
Embodiments of the present invention will now be explained with 
reference to the accompanying drawings, of which: 

Figure 1 is a network diagram illustrating a prior art network 
25 architecture that employs a first distributed, network specific billing solution; 



• ■ ■ # 



Figure 2 is a network diagram illustrating a prior art network 
architecture that employs a second distributed, network specific billing 
solution; 

Figure 3 is a schematic diagram of an STP switching node; 
5 Figure 4 is a schematic diagram that illustrates an embodiment of a 

Multi-protocol Gateway (MPG) routing and accounting node of the present 
invention; 

Figure 5 is a schematic diagram that illustrates a Multi-protocol Link 
Interface Module (MLIM) card and a processing flow path associated with an 
10 inbound signaling message; 

Figure 6a is a table that illustrates a Multi-protocol Routing Database 
(MRD) which includes a Signaling System 7 (SS7) key structure; 

Figure 6b is a table that illustrates a Multi-protocol Routing Database 
(MRD) which includes an Internet Protocol (IP) key structure; 
15 Figure 7 is a schematic diagram that illustrates a Multi-protocol Link 

Interface Module (MLIM) card and a processing flow path associated with an 
outbound signaling message; and 

Figure 8 is a table that illustrates a sample Usage and Measurements 
Database (UMD) structure and data. 

20 

Detailed Description of the Invention 
Disclosed herein are several embodiments of the present invention, 
all of which include a network element that performs functions similar to that 
of a traditional telecommunications network packet routing switch, such as a 
25 Signal Transfer Point (STP). Each of the embodiments described and 




discussed below, employs an internal architecture similar to that of high 
performance STP and signaling gateway (SG) products which are marketed 
by the assignee of the" present application as the Eagle® STP arid IP^ 
Secure Gateway™, respectively. A block diagram that generally illustrates 
5 the base internal architecture of the IP^ Secure Gateway™ product is shown 
In Figure 3. A detailed description of the Eagle® STP may be found in the 
Eagle® Feature Guide PN/91 0-1 225-01. Rev. B, January 1998. published by 
Tekelec, Inc. of Calabasas, California, the disclosure of which is hereby 
incorporated herein by reference. Similarly, a detailed description of the IP^ 

10 Secure Gateway™ may be found in Tekelec publication PN/909-0767-01, 
Rev B, August 1999. titled Feature Notice IP^ Secure Gateway™ Release 
1.0, the disclosure of which is hereby incorporated by reference. The 
specific functional components of an IP^ Secure Gateway™ for transmitting 
and receiving Transaction Capabilities Application Part (TCAP) messages 

15 over an Internet Protocol (IP) network are described in PCT Publication No. 
WO 00/35155, published June 15. 2000. the disclosure of which is 
incorporated herein by reference in its entirety. Similarly, the specific 
functional components of an IP^ Secure Gateway™ for transmitting and 
receiving ISDN User Part (ISUP) messages over an Internet Protocol (IP) 

20 network are described in the above-referenced PCT Publication No. 
WO 00/35156. 

As described in the above referenced Eagle® Feature Guide, an 
Eagle® STP 250 includes the following subsystems: a Maintenance and 
Administration Subsystem (MAS) 252, a communication subsystem 254 and 
25 an application subsystem 256. The MAS 252 provides maintenance 
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communications, initial program load, peripheral services, alarm processing 
and system disks. The communication subsystem 254 includes an 
I nteTprocessor Message Transport (IMT) bus that is the main communication - 
bus among all subsystems in the Eagle® STP 250. This high-speed 
communications system functions as two 125 Mbps counter-rotating serial 
buses. 

The application subsystem 256 includes application cards that are 
capable of communicating with the other cards through the IMT buses. 
Numerous types of application cards can be incorporated into STP 250, 
including but not limited to: a Link Interface Module (LIM) 258 that provides 
SS7 links and X.25 links, a Data Communication Module (DCM) 260 that 
provides an Internet Protocol (IP) interface using Transmission Control 
Protocol (TCP), and an Application Service Module (ASM) 262 that provides 
global title translation, gateway screening and other services. A Translation 
Service Module (TSM) 264 may also be provided to support local number 
portability service. While multiple application modules or cards may be 
simultaneously configured and operatively connected to the IMT bus, it will 
be appreciated that each card is assigned a unique IMT bus address so as 
to generally facilitate the internal communication of messages between 
provisioned application cards that are attached to the bus. Once again, a 
detailed description of the Eagle® STP other than DCM 260 is provided in 
the above-cited Eagle^ Feature Guide and need not be described in detail 
herein. DCM 260 is described in detail in one or more of the above- 
referenced PCT publications. 
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With particular regard to communication type modules, it should also 
be appreciated that in a manner similar to conventional SS7 LIM cards, the 
above mentioned DCM card can be employed to provide for the transport of 
Internet Protocol (IP) encapsulated SS7 messages over an IP network, as 
5 described in the above referenced Feature Notice IP^ Secure Gateway^^ 
Release 1.0 publication. With regard to the TSM module and triggered LNP 
services mentioned above, a detailed description of the Tekelec triggered 
LNP solution may be found in the Feature Guide LNP LSMS PN/910-1598- 
01, Rev. A. January 1998, published by Tekelec, Inc. of Calabasas, 

10 California, the disclosure of which is hereby incorporated herein by 
reference. Furthermore, systems and methods for providing triggerless LNP 
functionality within a network routing node are described in commonly- 
assigned, co-pending U.S. Patent Application No. 09/503,541, filed February 
14, 2000, the disclosure of which is incorporated herein by reference in its 

15 entirety. 

Shown in Figure 4 is one embodiment of a Multi-Protocol Gateway 
(MPG) packet routing switch of the present invention, generally indicated by 
the numeral 300. MPG 300 is adapted to route message packets between 
two dissimilar communication networks, and to further provide message 

20 accounting and billing services associated with such inter-network routing. 
As discussed briefly above, MPG routing and accounting node 300 employs 
an internal architecture that is similar in design and operation to that of an 
Eagle® STP and an IP^ Secure Gateway As such, MPG node 300 
generally includes an Interprocessor Message Transport (IMT) bus 304 that 

25 is the main communication bus among all subsystems in the node. MPG 
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node further includes a Maintenance and Adnninistration Subsystenn (MAS) 
302. Again, MAS 302 provides maintenance connnnunications, initial program 
load/ periplieral services, alarm pTocessing an^ 

The MPG shown in Figure 4 also includes a pair of MLIM cards, 310 
and 350, and an integrated message accounting and billing subsystem. In 
the particular embodiment shown, the message accounting and billing 
subsystem is comprised of a Multi-protocol Accounting Service Module 
(MASM) 380 and an external Accounting Server Platform (ASP) 400. From 
a practical implementation standpoint, ASP 400 could assume the form of a 
Sun Workstation or similar type computing platform. It will be further 
appreciated that the entire message accounting and billing subsystem could 
also be integrated within the MPG switch, such that no significant external 
computing platform is required. 

It will also be appreciated that the MLIM and MASM cards 310, 350, 
and 380, respectively, are connected via the shared, internal high speed IMT 
communications bus 304, and that multiple application cards (e.g.. MLIMs, 
LIMs, DCMs, TSMs, ASMs, etc.) can be simultaneously configured and 
operatively connected to the IMT bus. 



Shown in Figure 5 is one embodiment of a Multi-protocol Link 
Interface Module (MLIM) card 310 that is configured to transmit, receive, and 
generally facilitate communication between two communication networks 
that employ dissimilar signaling and transport protocol suites. MLIM 310 is 
somewhat similar in function and form to a conventional LIM, as described in 



Multi-protocol Link Interface Module (MLIM) 





the above referenced Tekelec Eagle and IP^ Secure Gateway product and 

I 

design publications. The MLIM, described herein, expands on the 
conventional LIM concept so as to provide the additional capability to 
communicate signaling information between dissimilar networks that utilize a 
variety of non-SS7 based signaling protocols and non-MTP based transport 
protocol suites. 

In general an MLIM card may be configured to include one or more 
transport protocol suite processes. In the example illustrated in Figure 5, 
MLIM card 310 is provisioned to support three transport protocol suite 
processes: a TCP/IP process 312, an MTP process 314, and an SCTP/IP 
process 316. Associated with each of the transport protocol suite processes 
312, 314, and 316 is an input / output (I/O) queue 318, 320, and 322, 
respectively. It will be appreciated that these lower level protocol process 
can be configured via hardware, software or firmware to support the 
physical, data link, network, and transport layers of a variety of transport 
protocol suites such as MTP, TCP/IP, SCTP/IP, UDP/IP and others. As 
discussed previously, these lower level transport protocol suite processes 
are responsible for implementing the functions and services generally 
associated with OSI levels 1 through 4. 

MLIM 310 further includes a Multi-Protocol Routing Process (MPRP) 
324, which is comprised of a Routing and Accounting Manager (RAMG) 
process 326, a Multi-protocol Routing Database (MRD) process 328, and a 
plurality of signaling protocol specific translation processes. More 
specifically, in the particular example shown in Figure 5, MLIM 310 is 
provisioned to include a TALI signaling protocol translation process 330, an 

n 




H.323 signaling protocol translation process 332, an SS7 signaling protocol 
translation process 334, a SIP signaling protocol translation process 336, 
and an NCCP signaling prdtocoF translation "process 338. It will be ~ 
appreciated that each of these signaling protocol translation processes is 
adapted to receive an incoming signaling message that is formatted in a first 
signaling protocol and subsequently translate the contents of this message 
into a second signaling protocol. For instance, in the specific example 
illustrated in Figure 5, an SS7 signaling protocol message is received at 
MLIM 310 and subsequently delivered to NCCP signaling protocol 
translation process 338, where the SS7 formatted message content is 
parsed and translated into an NCCP formatted signaling protocol message. 
As discussed above, an NCCP formatted signaling message is a normalized 
ISUP signaling message used by IP nodes in an IP network. 

A discussion of the specific messages translated by protocol 
translation processes 330, 332, 334, 336, and 338 is beyond the scope of 
this disclosure. What is important for purposes of the present invention is 
that lower layer and upper layer multiprotocol translation functionality, as well 
as accounting functionality, be located in the same network element or in 
one or more devices closely-coupled to the same network element. 
Providing the functions in the same network element greatly facilitates 
multiprotocol message routing and accounting, as will be discussed in more 
detail below. 

In addition, the present invention is not intended to be limited to the 
protocol translation processes illustrated in Figure 5. For example, other 
protocol translation processes, such as M3UA, SUA, M2UA, M2PEER, IDA, 

It 
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MAP and WAP may be substituted for or included in addition to the 
processes illustrated in Figure 5 without departing from the scope of the 
invention. ~ 
MLIM 310 also includes an HMDT process 340 that is responsible for 
5 the internal distribution of messages that require processing by other 
subsystems (e.g., accounting and billing, local number portability, calling 
name delivery, etc.) in the MPG node, and an HMRT process 342 that is 
responsible for the internal distribution of messages that are being routed or 
through switched from one MLIM card to another. 

10 With particular regard to the Routing and Accounting Manager 

(RAMG) process 326, it will be appreciated that RAMG process is adapted to 
receive incoming signaling messages and determine; (1) whether routing 
address translation is required, (2) whether transport suite protocol 
translation is required, (3) whether signaling application protocol translation 

15 is required, and (4) whether accounting of the message is required. If 
message accounting is required, RAMG process 326 is configured so as to 
produce a new message that is subsequently delivered to an associated 
accounting & billing subsystem. With particular regard to determining the 
need for transport suite protocol translation, it will be appreciated that such a 

20 need may be indirectly implied with the selection of an outbound 
communication link, port or socket. 

In any event, the above-mentioned four determinations are made with 
the assistance of an associated Multi-protocol Routing Database (MRD) 
process 328, As generally indicated in Figures 5a and 5b, MRD process 328 

25 may be comprised of multiple database table structures depending upon the 
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particular MLIM configuration employed. More particularly, Figure 6a 
illustrates a sample MRD database structure 600 that might be associated 
with ah MLIM card thaf is configuTed to communicate with an SS7 network. 
Figure 6b illustrates a sample MRD database structure 602 that might be 
associated with an MLIM card that is configured to communicate with an IP 
network. 

As such, it will be appreciated that if MLIM 310 configured with the 
MRD database 600 shown in Figure 6a receives an SS7 message destined 
for a node with an SS7 network address PC: 2-1-1 and SSN: 50, a lookup in 
the MRD database 600 would subsequently inform the RAMG process 326 
that: (1) the appropriate destination address is PC: 2-1-1, SSN: 50 (i.e., no 
routing address change is necessary); (2) the appropriate destination 
address requires an SS7 formatted message (i.e., no transport suite or 
signaling protocol translation is necessary); and (3) the accounting 
subsystem should not be notified (i.e., no accounting of this message is 
necessary). Consequently, in this example scenario, the received SS7 
signaling message would simply be routed or through switched. 

However, it will be appreciated that if MLIM 310 configured with the 
MRD database 602 shown in Figure 6a receives an SS7 message destined 
for an SS7 network address PC: 1-1-1. a lookup in the MRD database 602 
would inform the RAMG process 326 that: (1) the appropriate destination 
address is an IP socket comprised of an IP address. 102.20.20.10, and an IP 
port 22; (2) the appropriate destination address requires an NCCP formatted 
message; and (3) the accounting subsystem should be notified. 
Consequently, the received SS7 signaling message would be passed from 




the RAMG process 326 to the NCCP signaling protocol translation process 
338. 

NCCP translation process 338 Wduld subsequently exannine the 
infornnation content of the original SS7 message and generate an equivalent 
5 NCCP-formatted message, as per a pre-determined set of SS7-to-NCCP 
inter-protocol message type conversion rules. Such inter-protocol message 
type conversion rules might include, for example, instructions or rules for 
creating the NCCP equivalent of an ANSI ISUP lAM message. Furthermore, 
such conversion rules could include instructions for creating the NCCP 

10 equivalent of an 800 number, local number portability (LNP), or calling name 
(CNAM) SS7 TCAP query message. 

It will be appreciated from Figures 4, 5, and 6a, that once processing 
is completed NCCP translation process 338 passes the translated message 
on to HMRT process 342 for internal routing to the appropriate outbound IP- 

15 configured MLIM card that maintains TCP or UDP socket 1, with a 
corresponding IP address: 102.20.20.10, port 22. In the particular example 
present herein, TCP or UDP socket 1 has been established and is 
maintained on MLIM 350, and MLIM 350 has been assigned an IMT bus 
address identifier of 2201. As such the NCCP formatted message is 

20 internally routed to the outbound MLIM 350 and transport level protocol suite 
translation is effectively performed by the NCCP - TCP/IP socket process 
354, as indicated in Figure 7. In general, the outbound socket process is 
adapted to provide and apply the proper lower level transport protocol suite 
to the outbound signaling message so as to effectively prepare the outbound 

25 signaling message for transmission through the destination network. 



It will be further appreciated that an incoming message could be 
translated or converted based on a domain name (DN) or an email address 
type identifier, as generallyTndlcated in database table 602 (Figure 6b), As 
mentioned previously, it is also possible to translate from any one of the 
5 industry standard signaling protocols (e.g., SS7, SIP, H.323, etc.) to a 
normalized signaling protocol. Such a normalized protocol could be any 
protocol adapted to facilitate efficient translation of signaling information and 
to further provide a universal signaling protocol that can be easily utilized by 
nodes that are required to provide service to a variety of signaling networks. 

10 With particular regard to the message accounting and billing 

functionality of the MPG routing node 300, it will be appreciated that in one 
embodiment of the present invention, RAMG process 326 formulates an 
accounting message, related to a received signaling message, and passes 
this accounting message on to the HMDT process 340 for subsequent 

15 delivery to and processing by the MASM module 380, as generally indicated 
in Figure 4. It will be appreciated that the accounting message could simply 
be a copy of the original received signaling message, or the accounting 
message could be of a message type associated specifically with the 
accounting subsystem. In a preferred embodiment, a normalized accounting 

20 message (NAM) format is employed that is analogous to the NCCP signaling 
protocol concept. That is, a NAM formatted accounting message employs a 
field or record structure that is essentially a superset of all parameters of 
interest from all signaling protocols of interest. As such, parameters of 
interest in a SIP formatted signaling message can be easily accommodated 

25 in a NAM accounting message, as can parameters of interest in an SS7 




formatted signaling message. It will be appreciated that, in one embodiment, 
a NAM accounting message can be encapsulated within an SCCP packet 
prior to internal routing within the MPG node. Such SCCP encapsulation 
can be performed by a RAMG process. It will be further appreciated that the 
NAM format can be periodically expanded (or revised) to accommodate new 
or evolving signaling protocols that must be supported by an MPG node. In 
any event, the accounting subsystem is notified of the receipt of the 
incoming message. 

Message Accounting Subsystem 

In the embodiment illustrated in Figure 4, MPG node 300 includes a 
message accounting and billing subsystem that is comprised of an internal 
MASM card 380, and an external ASP accounting sen/er platform 400. It will 
be appreciated the combination of MASM card 380 and ASP accounting 
server 400 includes the database and control processes necessary to 
achieve the accounting and billing functionality of the present invention. 
Again, it should also be appreciated that the entire message accounting 
subsystem could also be integrated completely within the MPG node. 

The MASM card 380 shown in Figure 4 includes a Signaling 
Connection Control Part (SCCP) subsystem 382 that is responsible for 
receiving and preliminary processing of incoming SCCP encapsulated 
accounting message packets. MASM card 380 also includes an SCCP 
controller known as a Signaling Connection Routing Controller (SCRC) 
process 384 and a high-speed Ethernet Controller (EC) process 386. Once 
again, as described above, the SCCP subsystem 382 is responsible for 
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receiving and prelinainary processing of inconning SCCP encapsulated 
message packets, while the SCRC process 384 is responsible for 
discrinnination and subsequent distri&ution of messages based on 
information contained in an SCCP packet. In the case of MASM card 380, 
5 messages that satisfy the SCRC discrimination criteria are distributed or 
directed to the high-speed Ethernet Controller process 386. EC process 386 
is in turn responsible for controlling the process of communicating 
messages, via an Ethernet connection to and from the associated ASP 
server 400. More particularly, ASP server 400 includes a corresponding 

10 high-speed Ethernet Controller process 402 that serves as the 
communications interface between MASM card 380 and an on-board 
Accounting Server Manager (ASM) process 404. ASM process 404 is 
responsible for the de-capsulation or removal of the SCCP envelope that 
contains the accounting message. The de-capsulated accounting message 

15 is then passed to an adjacent Usage and Measurements process 406 where 
usage and measurement statistics are created and stored in a Usage and 
Measurements Database (UMD) 410, such as that shown in Figure 8. 

Usage and measurements statistics produced by such a process 
could include, but are not limited to, peg counts of messages received from a 

20 specific network address, a specific service provider, a specific service user, 
a specific IP socket, or a specific signaling link. As shown in sample UMD 
410. each "call" or communication is identified by a call ID, and certain 
predetermined information associated with a "call" or communication can be 
stored in the database. It will be appreciated that the information contained 
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in a UMD database could be significantly more or less detailed than that 
indicated in the example shown in Figure 8. 

In any event, such statistics could include information associated with 
the time-of-day that a message was received, the duration of a "call" or 
5 communication, general quality of service (QoS) indicators associated with a 
"call" or communication, information related to or identifying the type of 
service that is associated with a "call" or communication (i.e., broadband 
service related, call setup related, database query related, etc.). Such usage 
information could be used to bill a subscriber at different rates depending 

10 upon the type of sen/ice requested. For instance, a subscriber could be 
billed at one rate for a "call" or communication related to the downloading of 
a movie from a video server, and a different rate for a "call" associated with a 
real-time video - telephone conference. With such capability included within 
an MPG routing node, network operators greatly increased flexibility with 

15 regard to service-specific billing, without significantly increasing network 
OA&M requirements. 

In order to facilitate such billing operations, ASP server 400 also 
includes a billing process 408 that is adapted to extract information stored by 
the Usage and Measurements process 406 and subsequently generate bills. 

20 Once again, information or parameters maintained by process 406 that may 
be used in the generation of bills could include, but is not limited to. a 
network address identifier, a service provider identifier, a service user 
identifier, an IP socket identifier, a signaling link identifier, and a service type 
identifier. It will be further appreciated that a network address identifier could 

25 include, but is not limited to a destination or origination 887 point code, a 
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destination or origination IP address, and a destination or origination domain 
name. Similarly, a user identifier could include, but is not limited to a calling 
or called party telephone number, and a destination or briginatiori email" 
address. 

5 Furthermore, in the particular embodiment shown, copies of incoming 

signaling messages that require accounting service are encapsulated within 
an SCCP packet and subsequently internally routed to MASM 380. It should 
be appreciated that SCCP encapsulation is not essential to the operation of 
the message accounting subsystem of the present invention. Other internal 

10 encapsulating protocols could be just as easily employed, provided that a 
suitably provisioned MASM module is capable of receiving and processing 
the encapsulated messages. In fact, no encapsulation necessarily need be 
performed, so long as the accounting message generated by a RAMG type 
process can be received and generally processed by a suitable configured 

15 MASM module. 



Multi-Protocol Gateway (MPG) Operation 

In the example configuration shown in Figure 4, a first MLIM 310 is 
configured to communicate with an SS7-MTP network 500, while a second 

20 MLIM 350 is configured to communicate with an NCCP-TCP/IP network 502. 
As generally indicated in Figure 4. a first message is received by the first 
MLIM card 310 via an SS7-MTP Port process 314, herein identified by a Port 
ID of 3. It will be appreciated that MLIM card 310 has been assigned an 
internal IMT bus address identifier of 4101. As indicated in Figure 4, it is 

25 assumed that the first message was sent from a node 504 residing in the 




SS7 network 500. Furthermore, node 504 is identified within the SS7 
network by a point code (PC) value of 2-1-1, while the first message is 
addressed to a destination point code (DPC) vafue of 1-1-1. Lower level 
transport protocol suite processing is performed on the incoming first 
message by Port process 314, and the first message is subsequently passed 
to an associated I/O queue 320. Following buffering in the I/O queue 320. 
the first message is passed to the RAMG process 326. RAMG process 326 
identifies the first message as having arrived via Port process 314, and 
directs a lookup in MRD database process 328 based on information 
contained in or associated with the first message. 

According to the sample routing rules provided in Figure 6a, an 
incoming message that is addressed to a DPC value of 1-1-1 will be 
subsequently routed to a network element having an IP address of 
102.20.20.10, port 22. . In this example, MLIM 350 has been assigned an 
IMT bus address of 2201. and as indicated in Figure 6a, a connection or 
socket to this IP address has been established and is being maintained on 
the MLIM card having an IMT bus address of 2201. More specifically, a 
TCP/IP socket having a socket ID of 1 has been established on MLIM 350, 
As further indicated in Figure 6a, the signaling protocol translation rule 
associated with the first message indicates the need to translate the 
received signaling message to an NCCP protocol prior to routing. 
Consequently, RAMG process 326 passes the first message to NCCP 
signaling protocol translation process 338 along with information returned by 
the MRD database lookup operation. NCCP signaling protocol translation 
process 338 receives the first message and performs the SS7 to NCCP 
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translation or mapping operation, thereby effectively creating a second, 
functionally equivalent NCCP formatted signaling message. 

As generally indicated in Figure 5, the second NCCP formatted 
message is subsequently passed from the NCCP signaling protocol 
5 translation process 338 to HMRT process 342. HMRT process 342 identifies 
the destination MLIM card corresponding to IMT bus address 2201, and 
places the second signaling message on the IMT bus 304. The second 
message is then received by the MLIM card 350, and essentially directed to 
the outbound I/O queue 352 associated with the destination TCP/IP socket 

10 process 354. Socket process 354 next receives the NCCP formatted 
signaling message and constructs or appends the appropriate lower level 
transport protocol suite required to facilitate transmission to the destination 
node through TCP/IP based network 502. With lower level transport protocol 
suite processing complete, the NCCP formatted signaling message is 

15 transmitted into the TCP/IP based network 502, as generally indicated in 
Figure 4. 

Returning to Figure 5, it will be appreciated that following the MRD 
database lookup operation described above, RAMG process 326 is adapted 
to generate a NAM formatted accounting message that is associated with 

20 the first signaling message. This accounting message is produced in 
response to the instructions returned by the MRD process 328, indicating 
that message accounting service is required for the first signaling message. 
In the embodiment of the present invention presented herein, the accounting 
message assumes the form of a NAM message that is essentially 

25 encapsulated within an SCCP formatted packet. This SCCP encapsulated 
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message is subsequently directed to HMDT process 340. which in turn 
directs the SCCP encapsulated accounting message to MASM card 380 via 
IMTbus304. 

Once again, although an SCCP formatted accounting message is 
5 indicated in the particular embodiment shown in Figure 4 and described 
herein, it should be appreciated that the message directed to accounting 
subsystem need not be of an SCCP format. Other message formats could 
be employed, so long as the MASM card(s) were configured to receive and 
process the chosen account message format. 

10 The encapsulated accounting message is received and processed by 

SCCP process 382 that is resident on MASM card 380, so as to verify and 
generally validate the SCCP packet prior to further processing. The SCCP 
packet is next passed to the SCRC process 384, which is responsible for 
discrimination and subsequent distribution of messages based on 

15 information contained in the SCCP packet. Messages that satisfy the SCRC 
discrimination criteria are distributed or directed to the high-speed Ethernet 
Controller (EC) process 386. EC process 386 in turn communicates the 
SCCP message, via an Ethernet connection to the associated ASP server 
400, 

20 As such, the SCCP encapsulated accounting message is received by 

a corresponding EC process 402 and subsequently passed to the 
Accounting Services Manager (ASM) process 404. ASM process 404 
examines the received accounting message, removes the SCCP 
encapsulating layer and extracts the information from the NAM formatted 

25 accounting message according to a pre-determined set of usage and 
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measurement rules. This usage and measurement information is then 
provided to the Usage and Measurements process 406 for analysis and 
storage. Billing information may be generated by the accounting subsystem 
via the billing process 408. Billing process 408 extracts information from the 
Usage and Measurements process 406 and applies a set of pre-determined 
billing rate rules, so as to effectively generate invoices or bills indicating 
costs associated with various aspects of communication services. 

Other accounting services might include but are not limited to usage 
and measurements service, fraud detection service, and network 
management service. Although not explicitly shown, it will be appreciated 
that the external accounting server includes a user interface that provides a 
user-friendly method of extracting and utilizing the various accounting 
services data once it is collected. 



